home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Software Vault: The Diamond Collection
/
The Diamond Collection (Software Vault)(Digital Impact).ISO
/
cdr29
/
fga_os2d.zip
/
FGA.TXT
Wrap
Text File
|
1995-02-21
|
33KB
|
732 lines
─────────────────────────────────────
═══════════════════ The OS2DOS Frequently Given Answers ═══════════════════
─────────────────────────────────────
A selection of some of the frequently asked questions from the
International FIDONET OS2DOS echo, and, more importantly, their
frequently given answers. Preliminary version 0.01. 19950205.
Introduction
────────────
The International FIDONET OS2DOS echo is one of a family of several
echoes on FIDONET dealing with OS/2. OS2DOS deals specifically with
DOS and Windows programs running under OS/2, and anything to do with
OS/2's Virtual DOS Machines.
The FIDONET OS/2 Echo Family are backboned in all zones, and should be
available from locally all around the world. If you cannot find an
echo from the family, ask your sysop or your echomail feed.
This selection of Frequently Given Answers is by no means exhaustive,
but is meant to cover some of the more popular topics that regularly
come up in the echo.
Readers of the FGA are reminded to *ALWAYS READ THE OS/2 USER GUIDE*.
Neither the OS2 family of echoes, nor the FGA are meant as a
substitute for the user guide, and many topics that people regularly
ask about are in fact covered extensively in the user guide and the
on-line help for OS/2. The manual *is* your friend.
The OS2DOS FGA document is archived on DoNoR, one of the larger OS/2
sites in the United Kingdom. It is available for File Request 24
hours per day, every day of the year as OS2D-FGA.ZIP from 2:440/4.0.
Applications
────────────
■ What sorts of DOS and DOS+Windows applications will work under OS/2 ?
Almost all of them. The exceptions are detailed in the next answer,
and are actually restricted to a couple of specialised areas, as you
will see.
■ What sorts of DOS and DOS+Windows applications will not work under
OS/2 ?
There are essentially two sorts of softwares that will, by design, not
work under OS/2.
The first are those that attempt to write to the hard disc at a low
level, such as disc doctoring programs. Low level writes to the hard
disc from Virtual DOS Machines under OS/2 are not allowed, because DOS
disc doctoring programs are written with the assumption that nothing
else will be be accessing the disc at the same time as they are.
Since OS/2 is a multitasking system, this becomes a possibility. DOS
disc doctoring programs could thus cause consistency problems leading
to severe filesystem corruption were they allowed to write to the disc
directly at a low level.
Native OS/2 programs are allowed to write to the hard disc directly,
but they use OS/2 services (for which there are no DOS equivalents) to
negotiate obtaining exclusive access to the disc whilst doing so.
The second sort of software that will not by design work under OS/2
are those softwares that use the VCPI standard for DOS extenders.
VCPI is a dead standard, which died years ago. No-one supports it
these days, and programs that use it will only work on raw DOS. Most
DOS memory managers will prevent VCPI programs from running as well,
because VCPI demands total control of the entire machine.
If you find that software that you have bought relies on VCPI, send it
back *directly to the manufacturer* demanding a full refund. Don't
support authors of VCPI software by continuing to give them money.
Programs that use the newer DPMI DOS extender standard will not have
any such trouble under OS/2, as DPMI programs do not require total
control over the entire machine.
■ VxDs don't run under OS/2, do they ?
No they do not. VxDs are drivers for Windows that require the ability
to run in real mode when they start up. OS/2 *always* runs the
Windows kernel in v8086 protected mode. Running in real mode would
disable multitasking, and bypass all system protection, so OS/2 does
not support VxDs.
Most VxDs are kludges, written to provide support for unusual devices
to DOS boxes within Windows. Under OS/2, hardware support for unusual
devices in VDMs is provided by proper protected mode virtual and
physical device drivers, supplied by the manufacturer. Check with
your manufacturer for native driver support. All good manufacturers
can supply VDDs and PDDs for their hardware nowadays.
■ AutoCAD for DOS doesn't work under OS/2!
Oh yes it does. AutoCAD uses the Phar Lap DOS extender. Prior to
release 12c2 of AutoCAD, this DOS extender used VCPI. Subsequent
releases of the Phar Lap DOS extender use DPMI, and work under OS/2.
AutoDesk has been supplying an update to the Phar Lap DOS extender
almost since that release of AutoCAD. Call AutoDesk and ask for it.
While you are talking to them, ask them whether they've finished a
native OS/2 version of AutoCAD yet.
■ Microsoft Visual C++ for DOS doesn't work under OS/2!
Oh yes it does. Microsoft Visual C++ also uses the Phar Lap DOS
extender. However, Microsoft's tech support runs true to form, and
only makes fixes for its software available under protest. So your
best route is to obtain the fix from Phar Lap's BBS directly, or from
your nearest FIDONET site that is part of the Fernwood file
distribution system.
The Phar Lap DOS extender bugfix cures the problem with the
command-line tools in MSVC++ and allows them to run properly. The
Visual Workbench, however, uses a VxD as a back door into the
internals of the Windows kernel, allowing it to start up and control
DOS sessions under DOS+Windows, in particular for running NMAKE
"seamlessly".
When you come to generate programs in Visual Workbench, when you
receive the error message that VWB could not run NMAKE, simply start
another VDM within OS/2, and run NMAKE from there. You can even set
up a Workplace Shell program object to run NMAKE if you like. VWB
will have created the makefile properly for you. This has the
advantage of allowing you to compile and edit simultaneously, which
you normally cannot do with Visual Workbench.
Just FYI, you are suffering from always having to play catch-up by
using MSVC++. By past record, it is usually the last to adopt any
changes to the C++ language ("Not Invented At Microsoft"), and
bugfixes are rarely published ("Wait for the next version"). There
are far better C++ compilers available, such as Watcom C++ or Metaware
High C++, with much better update and bugfix policies. Watcom C++ can
even cross-compile DOS+Windows programs from a native OS/2 hosted
environment. But this is straying into the realms of the FIDONET
C_PLUSPLUS echo.
■ Doom for DOS doesn't work under OS/2!
Oh yes it does. Unfortunately, ID Software suffers from the sort of
tunnel vision that afflicts most games software houses. They like to
hit the hardware directly instead of using the device drivers. ID
accesses the sound card directly, and doesn't quite get it right.
Under DOS, this is unnoticable. Under OS/2, however, because of
multitasking the timing code goes wrong. This causes problems, and
sends ID's code into a flat spin.
To run any game that uses the ID Software game engine, such as
Doom or Heretic, switch the sound off and use the PC Speaker.
If you find that this spoils your enjoyment of the game, send the game
back *directly to the manufacturer* asking for a full refund, and
explain that you find it unsatisfactory that their sound facilities
don't work in the OS/2 multitasking environment.
■ I have a DOS application written by Borland. When it starts I
get half a page of gibberish, then the VDM ends with a SYS3176.
Borland's interpretation of the DPMI standard differs from that of
most other software manufacturers. In particular, Borland's software
initialises DPMI in a way different to the way that most other people
do it.
The rights and wrongs of it aside, the cure is easy. Go to the VDM
settings for that session object and change DPMI_DOS_API from AUTO to
ENABLED. This will work for any Borland application that uses the
Borland DPMI DOS extender (look for a DPMILOAD.EXE or RTM.EXE file).
■ I cannot install my Borland DOS program as a program object on the
Workplace Shell desktop. All of the buttons on the [Session] page of
the settings notebook are greyed out.
This is an artifact of Borland's proprietary DPMI DOS extender. Its
DOS extended programs are in the 16-bit New Executable EXE file
format, but they have a meaningless value in the "target operating
system" field in the executable file header.
This means that when Workplace Shell comes to inspect the executable
file header to determine what sort of session it needs to start the
program in, it finds illegal values and becomes confused.
The simple solutions are either to use a short batch file, or to use
"*" as the program name and "/C C:\BORDIR\BORPROG.EXE" as the program
parameters.
By the way, this information is in the Borland manuals for all of the
individual Borland DOS products. Why didn't you read the manual ?
The manual *is* your friend.
■ I have a game that doesn't work properly under OS/2!
Although it is not possible to provide a catch-all for DOS games
softwares (see the FGA for Doom for a note on the programming ethos of
some games software houses) some avenues to explore follow that often
yield results.
Try the memory settings. If the game says on the box that it requires
a minimum amount of extended memory, ensure that the extended memory
settings in the VDM settings dialogue are above that minimum. Do the
same for expanded memory.
If the expanded memory settings are set unreasonably high, and the
game still reports a problem with being unable to initialise expanded
memory, you may have a game written using VCPI. Check the
documentation for this, and if it turns out to be so, return it
*directly to the manufacturer* asking for a full refund.
Try the video settings. Some games require unusual video modes.
Since the video hardware is virtualised in VDMs, you may be required
to alter the VIDEO_8514A_XGA_IOTRAP and VIDEO_RETRACE_EMULATION
settings in the VDM settings dialogue for that session.
Incidentally, if you have not installed your video drivers properly in
the first place, DOS games will usually "discover" your error for you.
■ My DOS comms application has lots of errors. What can I do ?
Really, this is one of the Frequently Given Answers in the FIDONET
OS2DOSBBS echo. Very briefly: you need a proper buffering 16550 UART
when doing interrupt-driven comms, and you may also like to try Ray
Gwinn's SIO serial device drivers.
■ My DOS comms application is dead slow/slows down other applications.
What can I do to make things faster ?
This too is one of the FGAs in the FIDONET OS2DOSBBS echo. However,
here is an example of how to tune TELIX, which may help.
TELIX is a very poorly behaved application. It polls the keyboard and
the comms port almost continuously, and so wastes a lot of valuable
CPU time that could be used more productively by other applications.
Installing OSTSR or OS2SPEED helps somewhat, because TELIX knows how
to perform DesqView timeslice release calls. However, TELIX still
consumes a disproportionate amount of CPU time when doing file
transfers.
To reduce the impact of TELIX on other applications, leave it idle and
offline, and bring up Pulse. Gradually adjust the IDLE_SENSITIVITY
setting for the VDM running TELIX until Pulse falls to zero (which
will usually be around the 33 mark). This is by no means perfect,
but is the best general rule of thumb for TELIX that there is.
Of course, if you use TELIX, you might as well do the sensible thing
and upgrade to LiveWire for OS/2. After doing so, you'll realise just
how bad TELIX really was. Of course, native OS/2 comms softwares are
properly the subject of a different Frequently Given Answers document.
Utilities
─────────
■ How do I start another session from within a VDM ?
There are several utilities available to do this.
JP Software's excellent 4DOS replacement command interpreter comes
complete with a START command, that mirrors most of the function of
the START command available at a native OS/2 command line. The /DOS
switch, that is used to start VDMs, can take an optional argument to
specify the name of a file containing the VDM settings to use.
Other utilities include STARTD, DSTART, and HSTART, which all behave
similarly to 4DOS' built-in START command, and all of which are widely
distributed on file sites across FIDONET.
■ My software knows how to release timeslices to DesqView, but not
to OS/2. What can I do ?
There are two utilities available to convert DesqView timeslice
releases into OS/2 timeslice releases, namely OS2SPEED and OSTSR,
both of which are widely available on FIDONET OS/2 file sites.
You can File Request OSTSR and its companion program OSTITLE from Jay
Clegg's home node, 1:360/12.0, as OSTSR12.ZIP (14Kb). If you do,
please drop him a short note just to say hello as well.
■ I've installed OS2SPEED, and 4DOS now causes my VDMs to abort!
Really you should read the 4DOS on-line documentation, because this is
explained there. 4DOS is DesqView aware, and is fooled by OS2SPEED
into thinking that it is running under DesqView. It attempts to hook
into DesqView, and goes haywire because it isn't actually there. You
need to adjust the DVCleanup setting in your 4DOS.INI file.
Now go and read 4DOS.DOC. The manual *is* your friend.
■ How do I defragment or repair my SuperFAT partitions under OS/2 ?
If you want an OS/2 solution, there are SuperFAT defragmentation
utilities available for OS/2. GammaTech sell a SuperFAT
defragmentation tool as part of their suite of disc maintenance
utilities. The Graham Utilites apparently come with a SuperFAT
defragmenter. SafePack for OS/2 is a SuperFAT defragmentation tool.
As for DOS defragmentation utilities, there are two problems.
The first is that DOS programs are not allowed to write to the hard
disc at a low level when run on OS/2, even though they are allowed to
read from it. This means that DOS defragmentation utilities must be
run by booting from a DOS boot disc. This is not such a major
problem.
The second is that not many defragmentation utilities are aware of
extended attributes. In SuperFAT partitions, the directory records
contain extra information for each file, pointing to its extended
attribute information. Some defragmentation utilities, most notably
PC-Tools COMPRESS, will complain that extended attribute pointers are
actually "errors" in the filesystem, and will "fix" them by wiping
them completely. This will cause severe problems.
People have reported good results with Norton SpeedDisk, and the
DEFRAG utility that comes with Novell DOS. However, it seems that
different versions of these softwares behave differently. Certainly
their behaviour with respect to extended attributes is not guaranteed
by the manufacturers.
It is wise *not* to run defragmentation utilities on a SuperFAT
partition if it is the OS/2 boot partition unless you are *sure* that
they will not zap EA pointers (or unless you have full backups),
because the Workplace Shell desktop depends heavily from EAs.
By far the best solution is to make the OS/2 boot partition an HPFS
partition. You won't need to run defragmentation software (you won't
be *able* to run *DOS* defragmentation softwares against an HPFS
partition), and in the event of an error HPFS will be more recoverable
than SuperFAT.
■ What are 4DOS and 4OS2 anyway ?
4DOS and 4OS2 are replacement command interpreters from JP Software,
that provide *many* features and improvements over the standard
command interpreters. 4DOS replaces COMMAND, and runs both on DOS and
in an OS/2 Virtual DOS Machine. 4OS2 is 4DOS' big brother, and
replaces CMD, the native command interpreter for OS/2.
This FGA won't go on at length about the many improvements and
facilities available in 4DOS and 4OS2, because there is not the room.
Suffice it to say that they make whole piles of extra utilities
unnecessary, and make life a lot more pleasant for the command line or
batch file user.
Both 4DOS and 4OS2 are discussed in the FIDONET 4DOS echo. The author
hangs out there as well. You can obtain 4DOS and 4OS2 from many
FIDONET file sites (ask in FIDONET 4DOS for your nearest one) and try
them yourself, since they are available on a try-before-you-buy basis.
The filenames to look out for are 4DOS55A.ZIP, 4DOS55B.ZIP,
4OS232A.ZIP, 4OS225B.ZIP, and JP4REF.ZIP. Full OS/2 installation
instructions for 4DOS and 4OS2 are contained in the package.
Configuration
─────────────
■ Do I need the Windows permanent swap file, 386SPART.PAR ?
No. When Windows is run in OS/2, all swapping is done by OS/2 to its
own (dynamically sized) swapfile, because OS/2 handles all memory
management. The Windows permanent swapfile may be deleted, since it
is just taking up valuable disc space for nothing.
■ What is WINDOS.COM ?
OS/2 needs to adjust the Windows kernel "on the fly" in order to make
it use an external DPMI server (i.e. OS/2) for its DOS extender. It
does this by using its own loader program, WIN.COM, to start the
Windows kernel on top of the VDM kernel. The loader program for
running the Windows kernel on top of a raw DOS kernel, that is
supplied with Windows itself, is renamed to WINDOS.COM.
When the OS/2-supplied WIN.COM detects that it is running on raw DOS
(as will happen in Dual Boot setups), it simply executes WINDOS.COM,
and the Windows kernel is loaded using the DPMI server built-in to
Windows for its DOS extender.
■ What is SuperFAT ? Is that like FAT ?
SuperFAT is a superset of the old FAT filesystem format. It includes
extra facilities for the storage of extended attributes for files.
The "EA DATA. SF" file in the root directory may look like a normal
file, and appears that way when using DOS+Windows (which expects the
old FAT format), but in fact it is maintained by the SuperFAT
filesystem driver to contain EA data for all files on the partition.
You cannot delete "EA DATA. SF" by the way, because when a file is
deleted the SuperFAT filesystem driver opens "EA DATA. SF" to delete
any extended attributes for the file. When you try to delete "EA
DATA. SF" itself, it is found to be already open, and the delete
operation fails.
In other words, leave "EA DATA. SF" alone.
Contrary to popular belief, the "WP ROOT. SF" file is not part of the
SuperFAT format. It is maintained by Workplace Shell, not OS/2
itself, and stores some WPS desktop settings for each drive. If you
delete "WP DATA. SF", Workplace Shell will re-create it next time
that you use WPS to access that drive.
■ Should I choose HPFS or SuperFAT ?
If you are free to make a choice, then HPFS is much the better choice.
It supports long filenames; it can handle partition sizes up to two
Terabytes; and especially it doesn't have the ridiculously large
cluster overheads when used on large partitions that SuperFAT does.
Most importantly, perhaps, is that HPFS is more recoverable than
SuperFAT. There is a lot more redundancy in the filesystem structure
for HPFS, and CHKDSK is thus far more capable of recovering lost data
on HPFS partitions in the event of errors or dirty shutdowns.
For the full HPFS/FAT discussion, and incidental discussions covering
partition size limitations, there are separate FGAs available in the
FIDONET OS2 echo covering these subjects.
■ Can I switch to HPFS without repartitioning ?
Well, yes and no. You must repartition, because HPFS is a different
partition type to SuperFAT. However, if you do not wish to lose data,
then you may wish to investigate Partition Magic, which is a
commercially available utility designed to enable you to alter the
partitioning of your hard disc without losing data.
Alternatively, you could take the opportunity to ensure that you have
proper off-line backups of all of your data.
■ Can DOS and DOS+Windows programs run from and use HPFS ?
When running under OS/2, yes, of course they can. Any partition that
OS/2 can read natively is available to DOS and Windows applications
running on OS/2, and will look like just another drive letter. This
covers HPFS, CD-ROM filesystems, and even network drives.
Unfortunately, the 8.3 filename limit is hard-coded into the vast
majority of DOS and Windows applications, so they won't be able to
"see" any filenames that are not in that format on partitions that
support long filenames (such as HPFS, NETWARE and LAN SERVER
filesystems).
Many OS/2 users are happily running their DOS and DOS+Windows
applications on all-HPFS systems.
■ Should I use Dual Boot or Boot Manager ?
Again, if you are free to make a choice, then Boot Manager is the way
to go. Not only does it give you more flexibility (it allows you boot
from partitions on your secondary disc units), but it also protects
you from yourself to some extent.
The dangers of Dual Boot are twofold. Firstly, it plays musical
chairs with your boot sector and configuration files every time that
you switch operating systems. This can, and does, cause confusion.
Virus detection softwares that checksum the boot sector will go barmy
every time that you use Dual Boot.
Secondly, Dual Boot tacitly encourages the mistaken belief that it is
all right to run DOS disc maintenance programs on an OS/2 SuperFAT
boot partition. Apart from the considerations mentioned in another
answer, even simply using some versions of DOS to manipulate files and
directories on SuperFAT partitions can mess up EA pointers (Novell DOS
file passwords will corrupt EA information on SuperFAT partitions, for
example).
■ What can I do to `tune' OS/2 in general ?
Chris Johnson of 1:208/610.0 maintains a list of "Performance Tips for
Power Users". Currently this is not yet available for File Request,
but if you netmail him at that address he should be happy to netmail
you a copy.
There are other documents and tools widely available that detail the
settings in CONFIG.SYS, although no information on their whereabouts
was available at the time of going to press. If you have such a
document, please netmail the details to the FGA maintainer for
inclusion here.
Hardware and drivers
────────────────────
■ My soundblaster doesn't work from Windows under OS/2!
The SoundBlaster drivers that shipped with Windows 3.1x are the ones
that were available several years ago. They had bugs in. In
particular, the Voyetra MIDI drivers as supplied with Windows 3.1x
will not work under OS/2. You can obtain updated versions of these
drivers from Creative Labs BBS or via Creative Labs Tech Support.
You should also note two further things.
Firstly, the DOS+Windows SoundBlaster drivers are written assuming
that they are running on a bare DOS machine. This means that when
they initialise (i.e. each time that a Windows VDM starts), they
reset the sound hardware. If your soundblaster is on a non-standard
port or interrupt, you *may* (depending from your exact hardware
configuration) need to run a utility from AUTOEXEC.BAT (which runs
every time that a VDM starts) to reconfigure your SoundBlaster.
Usually you will be using the OS/2 Multimedia SoundBlaster drivers, of
course.
Secondly, the SB hardware was not designed to be used by more than one
thing at once. If OS/2 is playing sounds, Windows within OS/2 will
not be able to, and vice versa. OS/2's multitasking is nice, but it
doesn't magically cure hardware deficiencies.
Sound hardware like the PAS16 can be used from OS/2 and Windows under
OS/2 simultaneously, because it contains two sets of circuitry.
Configure Windows to use the SoundBlaster circuitry, and OS/2 to use
the PAS circuitry.
■ I cannot get MSCDEX to work under OS/2!
You're doing things wrong. MSCDEX is the DOS way of doing things.
OS/2 has proper native protected mode device drivers for accessing
CD-ROM devices. Just go into Selective Install and install them, and
all applications under OS/2 will be able to see your CD-ROM.
It used to be the case that some popular CD-ROM drives (mainly those
with proprietary non-SCSI interfaces) did not have OS/2 device
drivers. This was back in 1993, though. OS/2 now has device drivers
for the vast majority of CD-ROM drives. With WARP, they come right in
the box, and they are also available as packs from the various
manufacturers for users of older versions of OS/2.
For DOS programs, access to files on CD-ROM will be through normal
filesystem calls, which will be routed to OS/2, and the OS/2 CD-ROM
device drivers. Access to audio services, which is the other half of
what MSCDEX does for raw DOS, is provided by the VCDROM.SYS virtual
device driver, which is installed automatically when you install
CD-ROM support.
The only DOS program that cannot use CD-Audio without MSCDEX is
Terminate. Bo is checking for MSCDEX incorrectly, apparently.
Complain to him to get it fixed, or just ignore the CD features of
Terminate (why does a terminal program need this stuff anyway?) and
use the native OS/2 CD-Audio players.
( Before the advent of the CD-ROM device drivers in late 1993, the
Frequently Given Answer for MSCDEX use to explain at great length all
about how MSCDEX is one of the most ill-behaved DOS programs ever,
since it hooks into all sorts of version-specific back doors in the
DOS kernel, and how it is possible to patch it to skip the version
check. That is now not the best answer to the question. )
Programming
───────────
■ How do I detect when my DOS programs are running under OS/2 ?
The official method has always been to check the DOS version number.
OS/2 returns version numbers that are greater than 9. DOS version 20.x
is OS/2 version 2.x, for instance. You should always check that the
version number is greeater than or equal to a given number, and never
for an exact match.
This only works in a VDM, naturally, since a VMB runs a real DOS
kernel, which will report its real version number. There is no
reliable way to determine that you are running in a VMB.
■ How do I release timeslices under OS/2 ?
The call that you want is the standard INT 0x2F AX=0x1680 call, which
will release timeslices back to OS/2. Only use this call when your
program is really doing nothing other than polling, though. Rely on
the OS/2 scheduler to determine a priority for the VDM when your
program is actually doing useful work. It almost always gets things
right, and second guessing it usually makes things worse, not better.
Thank you for writing OS/2 friendly DOS programs. Please take the
next step and write proper native OS/2 programs. The people in the
FIDONET OS2PROG echo will be happy to help you with porting.
■ Anything else that I can do from DOS programs running under OS/2 ?
Well, yes. A lot of the old 16-bit OS/2 API is available via
semi-documented calls from within VDMs. You can find a list of them
in Ralph Brown's interrupt list.
But this is really making life too complex for yourself. If you want
to take advantage of OS/2 facilities such as semaphores and named
pipes, then write a native OS/2 program. The API is much easier to
call than messy DOS interrupts, and is exceedingly well documented.
There are a wide range of languages available for OS/2, from C++ to
FORTH, as well.
Technical Concepts
──────────────────
■ How does OS/2 support DOS and DOS+Windows applications ?
A normal OS/2 process runs in protected mode, and sees a simple, flat,
linear virtual memory space, which can be up to 512Mb. However, OS/2
can use the v8086 protected mode of the 386/486/586 CPUs to emulate
the environment and memory map that an ordinary DOS application would
see. This is what allows DOS and DOS+Windows applications to run
under OS/2.
Extended DOS applications usually run in `normal' protected mode, very
similar to normal OS/2 processes, in fact, except DOS extenders expect
the bottom megabyte of the virtual address space to contain a DOS
environment. OS/2 acts as a DOS Protected Mode Interface (DPMI)
server, to allow DOS programs to switch between normal and v8086
protected mode, and to manage memory in both.
The Windows kernel itself is architecturally no more than a DPMI DOS
extender. Windows applications run in normal protected mode, but rely
on the underlying DOS services for things like file access. Windows
uses the DOS Protected Mode Interface to switch back and forth between
normal protected mode and v8086 mode in order to service DOS calls
from Windows applications.
■ What about virtual memory ?
The memory map of a v8086 protected mode process has the same
conventional/upper/high/extended memory map that a machine actually
booted into DOS has. However, all of this is in fact virtual memory.
OS/2 pages the memory of any and all v8086 processes to and from disc
transparently. DOS and DOS+Windows applications are unaware of this.
Unlike DOS+Windows, under OS/2 the address spaces of all v8086
processes are entirely distinct. This prevents one session from
interfering with another, and also allows multiple sessions to be
configured differently.
■ What are VDMs and VMBs ?
Both VDMs and VMBs are OS/2 processes, and use normal OS/2 services.
However, they rely on translation layers to convert DOS services
requested by DOS or DOS+Windows applications into calls to OS/2
services.
A Virtual DOS Machine is colloquially known as "a DOS session", and is
where OS/2 emulates the complete DOS environment, including all DOS
services. It uses a built-in version of the DOS kernel, that maps
most DOS services directly onto their OS/2 equivalents.
A Virtual Machine Boot only emulates the BIOS portion of a DOS
environment, and `boots' a real DOS kernel on top. This kernel is
either an actual disc partition, a floppy disc, or an image file of
a disc partition or floppy disc.
■ When would I need a VMB instead of a VDM, and how do I go about
creating one ?
It is rare that you would need a VMB. The main reason for needing a
VMB is when a program requires access to the undocumented internals of
the DOS kernel. Since the DOS kernel used in a VDM merely translates
DOS services to OS/2 services, many of the undocumented internals of
the DOS kernel are absent. Programs that rely on these internals
require a `vanilla' DOS kernel, hence the reason for VMBs.
Fortunately, such programs are very rare. The most common ones are
DOS client networking softwares, and in most cases it is often simpler
to obtain the OS/2 client versions of the softwares (most networks,
including Netware and LANTastic, supply OS/2 client softwares, often
as part of the package).
To create a VMB, you simply change the DOS_STARTUP setting in the VDM
settings for that program object to point either to a driver letter or
to an image file.
To find out how to create an image file, read both the section in the
Master Help Index entitled "starting a specific version of DOS", and
the on-line help in the Command Reference under VMDISK.
■ What is the VMM and what are VDDs ?
The Virtual Machine Manager is the part of the OS/2 kernel that
handles setting up the v8086 process itself, and administering the
Virtual Device Drivers and, if necessary, the built-in VDM kernel.
Virtual Device Drivers are in control of emulating hardware and device
services for a VDM or VMB. The VCOM.SYS virtual device driver, for
example, emulates the physical UART hardware in each VDM/VMB,
translating all low level UART accesses into normal OS/2 API accesses
to the COM device.
Virtual Device Drivers are in fact what provide and interpret the "VDM
settings" that you see in the settings dialogue on the desktop.
For more information on VDDs and the internals of a VDM/VMB, consult
the Virtual Device Driver Reference published by IBM, which can be
found (along with a whole heap of other technical reference books) in
electronic form on the OS/2 Online Book Collection CD-ROM (IBM part
number 53G2166, costing roughly £30).
─────
(c) Copyright 1995. All Rights Reserved.
Permission is hereby granted to redistribute this document in original
form without modification, as long as no fee is charged, and as long as
you realise that I take no responsibility whatsoever for what it does to
your machine, data, cat, or marital status.
Jonathan de Boyne Pollard
Moderator, International FIDONET OS2DOS echo
FIDONET 2:440/4.3